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Introduction 


1.  Purpose.  The  purpose  of  this  memorandum  is  to  provide  documentation  of  the  project 
conducted  for  the  TRADOC  Analysis  Center,  Lee  (TRAC-LEE)  by  the  TRADOC  Analysis 
Center,  Monterey  (TRAC-MTRY).  This  project  seeks  to  enhance  the  capabilities  of  the 
Logistics  Battle  Command  (LBC)  model  in  two  key  areas:  updating  the  underlying  software 
architecture  from  32-bit  Java  (1.6)  to  64-bit  Java  (1.8)  and  the  development  and 
implementation  of  a  dynamic  attrition  module. 

2.  Background.  The  LBC  model  is  a  low-resolution,  object  oriented,  stochastics,  and  discrete 
event  model  programmed  in  Java  building  largely  on  the  Simkit  library.  The  primary 
purpose  of  the  LBC  model  is  to  support  sustainment  modeling  for  supply  consumption, 
distribution,  and  demand  in  order  to  support  analytic  efforts  routinely  conducted  by  TRAC- 
LEE.  The  original  development  of  LBC  occurred  in  2006  as  research  project  lead  by  TRAC- 
MTRY  in  collaboration  with  TRAC-LEE  and  the  Naval  Postgraduate  School. 

3.  Methodology.  We  separate  the  enhancement  of  the  Logistics  Battle  Command  model  into 
two  separate  problems  sets.  The  first  problem  set  is  to  upgrade  the  underlying  software 
architecture.  Appendix  B  covers  the  methodology  we  use  for  these  upgrades.  The  second 
problem  set  is  the  development  and  implementation  of  a  dynamic  attrition  module. 

Appendix  C  covers  the  development  and  mathematical  implementation  of  our  attrition 
model.  In  Appendix  D,  we  present  an  example  software  implementation  of  the  adjudication 
portion  of  the  attrition  module  in  the  Python  coding  language. 

4.  Results.  We  deliver  the  results  of  this  project  as  a  web  accessible  software  repository 
available  to  the  project  sponsor.  Additional  individuals  or  organizations  desiring  access  to 
the  latest  version  of  the  Logistics  Battle  Command  software  and  user  manual  should  contact 
the  TRADOC  Analysis  Center  -  Lee  or  TRADOC  Analysis  Center  -  Monterey. 


Study  Plan 

Problem  Statement 

To  enhance  the  capabilities  of  the  Logistics  Battle  Command  (LBC)  model  in  two  key  areas: 
updating  the  underlying  software  architecture  from  32-bit  Java  (1.6)  to  64-bit  Java  (1.8),  and  the 
development  and  implementation  of  a  dynamic  attrition  module. 

Project  Team 

Sponsor  Agency:  Morris  Hayes 

TRADOC  Analysis  Center  -  Lee 
morris.g.hayes.civ@mail.mil 

TRAC  Lead:  Nathan  Parker 

MAJ,  AV/FA49 

TRADOC  Analysis  Center  -  Monterey 


1 


nathan.l.parker8.mil@mail.mil 


NPS  Faculty:  Dr.  Arnold  “Amie”  Buss 

Modeling,  Virtual  Environments  and  Simulations  Institute 

Naval  Postgraduate  School 

abuss@nps.edu 

Constraints,  Limitations,  and  Assumptions 

•  Constraints 

-  The  project  must  be  completed  NLT  30SEP16. 

-  The  final  attrition  model  will  be  Unclassified. 

-  Software  tools  will  be  free  and  open  source. 

-  The  upgraded  LBC  software  will  to  run  on  Windows  7  and  current  MAC 
operating  systems  as  a  minimum  specification. 

-  The  upgraded  LBC  software  will  accept  Excel  and  MS  Access  as  minimum  input 
options. 

•  Limitations 

-  None 

•  Assumptions 

-  Free,  open  source  software  tools  are  sufficient  to  upgrade  the  LBC  architecture. 

-  By  adjusting  threat  density  and  type  in  the  input  parameters,  the  dynamic  attrition 
module  can  represent  the  full  array  of  combat  environments. 

-  Excel  and  MS  Access  data  tables  are  sufficiently  large  to  meet  all  future  Scenario 
requirements. 
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Methodology 


Background  Research 

>  Define  problem  statement. 

•  Conduct  literature  search  on: 

-  ADT  Model. 

-  TRADOC  G-2  Threat 
Assessment. 

-  Combat  Model 
Alternatives. 


LBC  Infrastructure 
Upgrade 

Update  to  JAVA  8. 

Replace  JDBC  -  ODBC  Bridge. 
Fix  Unit  Tests. 

Eliminate  compiling  errors. 

Fix  Javadoc. 

Read  EXCEL  inputs. 


o 


Convoy  Attrition  Model 
Development 

Develop  alternative  conceptual 
models. 

Compare  models  based  off  of 
conceptual  validation,  simplicity  and 
flexibility  to  threat. 


Final  LBC  Delivery 

Final  upgraded  LBC. 
Documentation. 


Convoy  Attrition 
Implementation 

Code  in  Java. 

Implement  Unclassified. 

Add  classified  parameters. 


Convoy  Attrition 
Verification 

Verification  tests  and  analysis. 

SME  Face  Validation. 

Data  can  be  Classified. 

Operational  Validity  tests  if  time 
permits. 

Select  1-3  simple  scenarios  to  verify 
functionality  across  scenarios. 


Figure  A-l.  Project  Methodology. 


Project  Timeline 

May  2015  -  Receipt  of  funds. 

June  2015  -  Initial  IPR  -  Review  current  LBC  capabilities. 

September  2015  -  IPR  #1  -  Review  architecture  upgrade  status. 

December  2015  -  IPR#2  -  Review  upgrades  and  attrition  module  requirements. 
January  2016  -  Conduct  literature  review  on  attrition  methods  and  code  initial  model. 
February  2016  -  IPR  #3  -  Review  attrition  methodology  development. 

March  2016  -  Test  the  attrition  model  on  an  array  of  mock  combat  scenarios. 

May  2016  -  Integrate  attrition  model  in  the  LBC  construct. 

August  2016  -  Final  IPR  -  Deliver  project  requirements. 
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Appendix  A  -  Architecture  Updates 


Upgrading  LBC  to  Latest  64-Bit  Java  Version 

The  previous  released  version  of  LBC,  3.15.0  only  ran  on  32-bit  Java,  which  limits  the  size  of 
the  scenarios  that  LBC  can  execute.  Furthermore,  it  uses  on  an  outdated  version  of  Java  (1.6). 
Therefore,  the  first  task  is  to  upgrade  LBC  to  the  latest  64-bit  Java  (1.8). 

Issues 

The  upgrade  to  64-bit  Java  exposed  several  problems,  the  most  serious  of  which  was  the  fact  that 
LBC  had  been  using  Java’s  JDBC-ODBC  bridge  to  connect  with  input  files,  particularly  MS 
Excel  and  MS  Access.  However,  Java  1.8  removed  the  JDBC-ODBC  bridge,  requiring  us  to 
locate  a  different  implementation  of  the  database  connectivity  (JDBC). 

The  next  issue  is  that  Java  1.8’s  Javadoc  processing  implements  doclint,  which  produces  errors 
for  non-HTML-compliant  comments.  Many  of  the  Javadoc  comments  in  LBC  now  fail  doclint 
and  require  correction.  Additionally,  these  discrepancies  cause  Java  to  throw  thousands  of 
warnings  in  addition  to  the  outright  errors  that  in  turn  cause  LBC  to  crash. 

A  number  of  LBC’s  dependent  libraries  are  out-of-date  and  require  updating.  This  is  particularly 
important  for  the  JDOM  package  that  parses  XML  files.  LBC  3.15.0  uses  the  old  JDOM  library, 
whereas  JDOM2  is  the  most  recent  version  and  contains  a  number  of  important  features, 
including  use  of  generics  in  processing  collections  of  XML  elements.  Other  libraries  that  require 
upgrades  include  the  NpsTracCommons  library. 

Finally,  many  unit  tests  in  LBC  3.15.0  fail,  even  when  running  in  the  older  32-bit  mode.  These 
errors  should  have  been  corrected  prior  to  the  release  of  LBC  3.15.0  and  will  require  correction 
prior  to  the  release  of  our  updated  version  LBC. 

In  summary,  we  accomplish  the  following  tasks  in  order  to  bring  LBC  into  full  compliance  with 
Java  1.8: 

1.  Convert  to  Open  Source  JDBC  Driver  and  update  input  processing  to  reflect  stricter  case- 
sensitivity  compliance. 

2.  Upgrade  all  the  dependent  libraries  to  the  latest  versions  of  each,  updating  LBC  code 
where  necessary  to  reflect  the  new  versions. 

3.  Fix  all  failing  unit  tests  -  modifying  those  necessary  to  be  in  full  compliance  and 
removing  those  that  depend  on  the  JDBC-ODBC  bridge. 

4.  Fix  all  Javadoc  errors  and  warnings  resulting  from  Java’s  doclint  program  being  stricter 
about  HTMF  compliance. 


A-l 


Open  Source  JDBC  Driver  for  MS  Excel  and  MS  Access 


A  constraint  on  the  LBC  upgrade  is  that  all  external  libraries  be  Open  Source.  Therefore,  while 
several  commercial  JDBC  drivers  exist  for  accessing  MS  Excel  and  MS  Access  files  they  are  not 
available  for  use.  Two  Open  Source  libraries  for  JDBC  access  to  Excel:  xlSQL  and  SQLSheet. 
While  each  of  these  libraries  provides  some  of  the  desired  functionality,  ultimately  neither  one  is 
adequate  for  LBC’s  needs. 

A  third  Open  Source  JDBC  driver  is  available  from  in  a  separate  project  by  the  developer,  titled 
movesDB.  This  pure-Java  JDBC  driver  supports  reading  both  Excel  spreadsheets  as  well  as 
Access  database  files.  While  it  currently  does  not  support  writing  via  JDBC,  that  functionality  is 
not  necessary  for  LBC  purposes.  Therefore,  we  select  movesDB  as  the  replacement  JDBC  driver 
for  the  obsolete  JDBC-ODBC  bridge. 

One  consequence  of  this  change  is  increase  in  the  case-sensitivity  of  table  names  and  column 
names.  Therefore,  we  will  modify  the  JDBCtoXML  class  in  LBC,  which  converts  inputs  to  XML 
format,  to  reflect  this  case  sensitivity.  Table  and  column  names  must  match  those  listed  in  the 
LBC  User  Manual  exactly,  up  to  and  including  case. 

Subsequently,  we  will  add  a  ColumnLint  program  to  LBC  in  order  to  identify  and  correct  table 
and  column  names  that  are  correct  except  for  case.  For  example,  the  table  “ScenarioData”  is  a 
required  one,  but  if  a  table  named  “scenarioData”  is  present  instead,  it  will  produce  an  error.  The 
ColumnLint  program,  when  run  on  that  input,  will  identify  the  error  and  write  the  correct  version 
of  the  input  file  in  a  separate  location. 

Upgrading  Dependent  Libraries 

We  upgrade  the  following  libraries:  JDOM  (to  JDOM2),  NpsTracCommon,  Simkit,  and 
TracBayes.  Additionally,  we  will  insert  the  latest  version  of  Simkit,  which  requires  only  minor 
updates. 

Unit  Tests 

The  upgrade  to  Java  1.8  will  cause  a  significant  number  of  the  unit  test  to  fail  due  to  their 
dependency  on  the  JDBC-ODBC  bridge.  Each  of  these  individual  unit  tests  will  require 
modification  prior  to  our  release  of  the  updated  version  of  LBC. 

Javadoc 

The  Javadoc  errors  mostly  consist  of  replacing  certain  symbols  with  the  corresponding  HTML 
code.  Lor  example,  in  Javadoc  comments  an  ampersand  (&)  must  be  replaced  by  &amp;  and 
greater-than/less  than  signs  (>  and  <)  replaced  with  &gt;  and  &le;,  respectively. 

The  warnings  mostly  consist  of  missing  Javadoc  for  parameters  and/or  return  values  for  methods. 
Since  there  are  thousands  of  these,  it  will  require  a  significant  amount  of  time  to  correct  them. 
These  modifications  are  necessary  to  ensure  the  Javadoc  for  the  upgrade  version  of  LBC  is 
compliant  with  general  standards. 
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Appendix  B  -  Dynamic  Attrition  Methodology 


Overview 

The  second  portion  of  this  project  focuses  on  the  development  of  a  dynamic  attrition 
methodology  and  the  subsequent  implementation  within  the  Logistics  Battle  Command  (LBC) 
model. 

Literature  Review 

Two  historic  attrition  methodologies  and  a  current  model  proposed  by  analysts  at  TRAC  -  Fort 
Leavenworth  (TRAC-FLVN)  inform  the  development  of  the  dynamic  attrition  methodology  we 
propose  for  LBC.  Each  of  these  methodologies  or  models  contributes  a  specific  part  to  the 
logical  development  of  our  dynamic  attrition  methodology. 

The  first  historic  attrition  methodology  we  consider  is  the  Lanchester  Equations,  specifically  the 
variation  proposed  by  Deitchman.1  This  work  provides  an  initial  option  for  modeling  attrition 
between  two  very  imbalanced  forces  such  as  an  ambush  style  attack.  However,  the  deterministic 
and  continuous  nature  of  the  Lanchester  equations  makes  them  incompatible  with  the  discrete 
event  construct  of  LBC.  Bullard  further  advances  this  methodology  by  developing  a  stochastic 
variation  of  the  Lanchester  equations.2  The  primary  concept  we  adopt  from  the  combination  of 
these  theories  is  the  ability  to  use  a  ratio  of  relative  combat  power  scores  to  determine  the 
transition  probability  in  a  discrete  Markov  process. 

The  second  historic  attrition  methodology  we  consider  is  the  Hughes  Salvo  equations.  While 
these  equations  find  their  widest  use  in  the  naval  warfare  community,  we  observe  several 
features  that  can  inform  our  dynamic  attrition  methodology.  The  Hughes  Salvo  equations 
consider  each  warship  as  a  discrete  entity  with  multiple  attribute  including  staying  power, 
striking  power,  defensive  capability,  and  more  depending  on  the  embellishment  under 
consideration.3  Lrom  the  Hughes  Salvo  equations,  we  draw  the  concept  of  treating  the  attacking 
and  defending  forces  as  holistic  entities.  Additionally,  the  calculation  a  relative  combat  power 
for  each  step  of  the  engagement  sequence  is  an  independent  event. 

We  also  consider  the  Attrition  Distribution  Tool  (ADT),  developed  by  TRAC-LLVN,  since  one 
of  its  intended  purposes  is  to  develop  attrition  distributions  for  use  in  non-combat  models  such  at 
LBC.  Our  primary  concern  with  carrying  the  ADT  forward  as  a  primary  component  of  our 
dynamic  attrition  model  is  the  high-resolution  inputs  the  model  requires.  We  find  it  unlikely  that 
future  modelers,  especially  those  conducting  logistic  analysis,  will  have  access  to  fidelity  of  data 
necessary  to  population  the  model.  These  complexities  also  make  any  sensitivity  analysis  or 
scenario  excursions  more  difficult.  The  ADT  developers  propose  a  zone  construct  for  modeling 


1  S.  J.  Deitchman.  A  Lanchester  Model  of  Guerrilla  Warfare.  Operations  Research  10(6):8 18-827.  http:// 
dx.doi.org/10.1287/opre.  10. 6. 8 18,  1962. 

2  L.  Billard.  Stochastic  Lanchester-type  Combat  Models  I.  Technical  Report  Naval  Postgraduate  School. 
http://hdl.handle.net/10945/30208,  1979. 

3  W.P.  Hughes  Jr.  Two  Effects  of  Firepower:  Attrition  and  Suppression.  Military  Operations  Research.  Vol.  2,  No.  1, 
Winter  1996. 
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the  array  of  enemy  forces  through  the  different  battlefield  areas  logistic  type  elements  are  likely 
to  operate.  We  find  this  construct  extremely  useful  and  plan  to  use  it  in  our  methodology. 

We  believe  that  the  primary  method  of  attack  against  a  logistics  element  is  an  ambush  style 
attack.  Two  different  types  of  ambush  style  attacks,  the  annihilation  ambush  and  the  harassing 
ambush,  will  form  the  basis  for  how  we  model  enemy  actions  in  our  dynamic  attrition  model.4 
In  the  annihilation  ambush,  the  attacker’s  primary  objective  is  to  exact  maximum  damage  on  the 
convoy  so  they  will  risk  becoming  decisively  engaged.  In  the  harassment  ambush,  the  attacker’s 
primary  objective  is  to  maintain  combat  power  so  they  will  not  risk  becoming  decisively 
engaged. 

Conceptual  Development 

Our  goal  is  to  provide  a  dynamic  attrition  model  that  sufficiently  represents  the  impacts  of 
attrition  on  logistics  operations  and  has  the  following  characteristics:  uses  level  of  resolution 
similar  to  that  of  LBC,  uses  input  data  readily  available  to  TRAC-LEE  analysts,  has  a  low 
computational  overhead  and  is  easy  to  understand  for  both  analysts  and  warfighters.  In  addition 
to  the  literature  discussed  above,  the  model  development  will  draw  heavily  on  the  combat 
experience  of  the  TRAC-MTRY  analysts  for  both  conceptual  development  and  face  validation. 

Red  Force  Representation 

We  will  represent  the  area  of  operations  as  a  series  of  zones  within  which  the  enemy  elements 
will  execute  attacks  against  convoys.  To  best  match  LBC’s  level  of  resolution  we  will  model 
attrition  at  the  vehicle  level  for  blue  (friendly)  elements  and  the  crew  served  weapon  (CSW)  for 
red  (enemy)  elements.  We  leave  the  specific  definition  of  a  CSW  up  to  the  analyst  using  the 
model  but  we  envision  the  definition  including  medium  and  heavy  machine  guns,  rocket 
propelled  grenades,  anti-tank  rockets,  and  improvised  explosive  devices.  We  also  implement  an 
aggression  level  parameter  for  each  zone  that  will  control  the  mixture  of  annihilation  and 
harassing  type  ambushes  allowing  the  model  to  cover  an  array  of  enemy  force  objectives.  Figure 
C-l  provides  a  depiction  of  this  implementation  concept. 


4  Headquarters  Department  of  the  Army.  Opposing  Force  Tactics.  Training  Circular  7-100.2.  Government  Print 
Office,  Washington  D.C.  201 1. 
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Zone  ->  Arc  Set 


Input  parameters  specify  the  threat  and  security  for  each  zone. 

Input  Parameters  (by  Zone) 

•  Red  Force  Elements. 

-  #  of  Crew  Served  Weapons  ->  Red  CSW 

•  Aggression  Level. 

-  Annihilation/Harassing  Ambush 

-  Ref.  TC  7-100.3 


Balance  fidelity  and  usability  to  match  existing  LBC  data. 


Figure  C-l.  Concept  sketch  for  the  array  for  Red  Force  elements. 


We  use  a  simple  discrete  event  construct  to  model  the  red  forces  cycle  of  attack  emplacement, 
execution  and  recovery  for  each  red  force  element.  Each  red  force  element  has  five  parameters: 
the  number  of  CSW  in  the  element,  the  element’s  effectiveness  level  [0-1],  the  mean  recovery 
time  if  the  element’s  previous  action  is  not  the  execution  of  an  ambush,  the  mean  recovery  time 
in  the  element’s  previous  action  is  the  execution  of  an  ambush,  and  the  mean  time  the  element 
will  spend  in  an  attack  position  before  it  withdraws.  Each  attack  element  randomly  chooses  an 
arc,  from  the  arc  set  of  their  zone,  on  which  to  set  up  their  ambush  each  time  they  become  active 
The  event  graph  in  Figure  C-2  depicts  this  process. 


Figure  C-2.  Event  Graph  for  the  generation  of  Red  Force  attacks. 
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Blue  Force  Representation 


The  existing  LBC  model  has  the  capability  of  representing  multiple  vehicle  types  within  the  blue 
force  structure.  We  leverage  this  capability  and  add  a  Blue  Escort  Vehicle  type.  Similar  to  the 
Red  CSW  concept,  we  leave  the  definition  of  what  is  an  Escort  Vehicle  up  to  the  model  user. 
Here  we  envision  an  armored  vehicle  with  a  crew  served  weapons  system  whose  sole 
responsibility  is  to  provide  security  for  the  logistics  convoy.  We  include  functionality  in  the 
model  to  allow  the  model  user  to  define  the  force  structure  of  the  Escort  Vehicles  and  to 
establish  business  rules  regarding  the  requirements  for  Escort  Vehicles  in  each  convoy. 

Model  Component  Integration 

The  red  and  blue  force  representations  discussed  above,  along  with  the  attack  adjudication 
methodology  we  will  develop  later  in  this  paper,  each  correspond  to  separate  model  components. 
At  the  software  implementation  level  we  employ  a  loosely  coupled,  modular  design  using  the 
Java  event  listener  construct  to  integrate  these  separate  components.  This  modular  design 
provides  flexibility  for  further  development  and  customization  since  it  is  easy  to  switch  out  one 
or  more  modules  as  along  as  the  input  and  output  formats  remain  the  same.  Figure  C-3  depicts 
the  simplicity  of  this  modular  design. 


Modular  framework  allows  for  future  flexibility. 


Existing  LBC 

Attack 

Attack  Engine 

(Convoy  Engine) 

Adjudicator 

Event  Listeners  connect  independent  modules. 


Figure  C-3.  Modular  framework  for  individual  model  components. 

Attack  Adjudication  Methodology 

To  limit  the  computational  complexity  our  attack  adjudication  method  invokes  the  Markov 
property  so  that  the  outcome  of  any  step  of  the  attack  sequence  depends  only  on  the  current 
conditions.  We  use  a  relative  comparison  of  the  current  red  and  blue  combat  powers,  along  with 
a  random  number  draw,  to  determine  who  suffers  the  loss  in  each  step.  To  further  limit 
complexity,  we  do  not  model  the  time  component  within  the  attack  sequence,  since  the 
magnitude  of  time  passage  in  an  ambush  style  attack  is  insignificant  given  LBC’s  level  of 
resolution.  Figure  C-4  depicts  the  inputs,  process,  and  outputs  steps  of  the  attack  adjudication 
sequence.  Subsequence  sections  will  develop  each  process  step  in  additional  detail. 
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Aggression 


Legend 


input 


Process 


Output 


Attack  Initiated 


E 


Blueyg^,  BlueEscort, 
dcswi  I 
R^dMode 


Determine  Attack  Type 
(Harass  or  Annihilation) 

'I' 

Calculate  Combat  Powers 

b 

Determine  Loss 

Update  Blue  &  Red  Forces 

b 

Check  Stopping  Conditions 

b 

Determine  Post-Attack  Action 

Results  output  to  Convoy  and 
Attack  Engines 

Figure  C-4.  Concept  sketch  of  the  attack  adjudication  methodology. 


Determining  Attack  Type 

We  determine  the  attack  type,  annihilation  or  harassment,  using  the  aggression  level  parameter 
from  the  associated  zone  and  a  random  number  draw  from  a  uniform  distribution.  Equation  3-1 
shows  how  we  determine  each  attack  type. 


Attack  Type  =  < 


Annihilation,  X  < 


Agression  Level 
100 


Harrassment,  otherwise 


Where  X  ~  £/[0,l] 


(C-l) 


We  employ  a  generalized  concept  of  each  attack  type  to  develop  the  engagement  sequence  and 
stopping  conditions  associated  with  each  type.  These  concepts  originate  from  the  Opposing 
Force  Tactics  training  circular  with  further  refinement  and  validation  from  the  TRAC-MTRY 
military  analysts.  We  provide  a  brief  explanation  of  each  attack  type  in  the  sections  below  along 
with  a  consolidated  reference  in  Figure  B-5.  The  limitations  and  structures  we  place  on  each 
attack  type  are  somewhat  arbitrary  and  future  users  may  desire  to  modify  these  features  to  fit 
individual  needs. 


B-5 


Harassment  Attack  Type 


For  the  harassment  attack,  we  assume  that  the  red  force  will  immediately  disengage  if  the  blue 
force  returns  effective  fire.  For  the  attack  sequence,  we  assume  that  the  attacker  will  target  the 
logistic  elements  of  the  convoy  to  maximize  the  impacts  on  the  logistics  system.  Additionally, 
we  assume  that  the  attacker  is  not  subject  to  attrition  but  rather  use  the  determination  of  a  red 
force  loss  as  a  stopping  condition  without  actually  enforcing  the  loss.  We  limit  the  maximum 
amount  of  damage  that  the  red  force  can  inflict  to  represent  their  intent  to  quickly  withdraw  from 
the  engagement  area  and  not  risk  decisive  engagement.  The  two  stopping  conditions  for  the 
harassment  attack  are  if  Blue  losses  reach  the  maximum  allowable  level  or  if  an  engagement 
outcome  is  a  Red  loss  (though  the  loss  is  not  enforced). 

Annihilation  Attack  Type 

For  the  annihilation  attack,  we  assume  that  the  red  force  is  seeking  a  decisive  engagement  and 
will  press  the  attack  until  they  expend  all  their  ammunition,  wipe  out  the  Blue  convoy  or  loss 
half  of  their  force.  For  the  attack  sequence,  we  assume  that  the  attacker  will  target  the  escort 
elements  of  the  convoy  first  to  eliminate  their  ability  to  mount  an  effective  defense.  We  limit  the 
number  of  blue  vehicles  that  the  red  force  can  destroy  to  represent  limitations  in  ammunition 
supply  and  the  limited  kill  zone  that  a  given  size  force  can  establish.  The  three  stopping 
conditions  for  the  annihilation  attack  are  if  Blue  losses  reach  the  maximum  allowable  level,  if  the 
Blue  convoy  is  annihilated  or  if  the  Red  losses  reach  the  maximum  allowable  level. 


Harassinq  Attack 

Annihilation  Attack 

•  Red  targets  Blue  Vehicles  first. 

•  Red  targets  Blue  Escorts  first. 

•  Blue  LossMax  =  Ceiling(l.  5  * 

•  Blue  LossMax  =  3  *  Red^s^ 

Redcsw) 

•  Red  LossMax  =  Floor{.  5  * 

•  Red  not  subject  to  attrition. 

Redcsw) 

•  Stopping  Conditions: 

•  Stopping  Conditions: 

-  Blue  Loss  =  Blue  LossMax 

-  Blue  Loss  =  Blue  LossMax 

-Red  “Loss” 

-  Red  Loss  =  Red  LossMax 

-  Blue  convoy  annihilated. 

Figure  C-5.  Summary  of  attack  type  engagement  sequence  and  stopping  conditions. 


Calculating  Combat  Power 

We  use  the  concept  of  combat  power  to  represent  the  capability  of  each  force,  red  and  blue,  to 
attrite  the  other  element.  The  Red’s  crew  served  weapon  systems  and  Blue’s  escort  vehicles 
provide  the  base  input  for  each  calculation.  For  the  blue  combat  power  ( Bluecp )  calculation 
(Equations  C-2  and  C-3),  we  account  for  both  the  overall  force  effectiveness  and  the  effect  of  the 
dispersion  of  escort  vehicles  within  the  convoy.  For  the  red  combat  power  ( Redcp )  calculation 
(Equations  C-4  and  C-5),  we  only  adjust  for  the  overall  effectiveness.  Here  we  use  a  random 
effectiveness  coefficient  from  a  triangular  distribution  using  one  user-defined  parameter.  We  use 
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this  distribution  as  an  example  to  show  how  one  might  add  additional  distributional  data  to  the 
adjudication  methodology. 


BlueCP  =  BlueEscorts  *  BlueEffectiveness  * Vehicle  Ratio  (C-2) 

Vehicle  Ratio  = - BlueEscons -  (C-3) 

BlllS Escorts  +  B^Ue Logistic  Vehicles 

RedCP  —  Redcsw  *  RedEgectivmess  (C-4) 

Red  Effectless  =™^Xrri(Red 

Mode  RedMode  +  -2’  RedMode  ).  ']  (C-5) 

Determine  Loss  for  each  Engagement  Step 

We  determine  the  loss  for  each  engagement  step  using  a  ratio  of  the  red  and  blue  combat  powers 
and  a  random  draw  from  a  uniform  distribution.  Equation  C-6  shows  how  we  determine  the  loss 
for  each  engagement  step. 


Engagement  Loss 


Blue,  X  < 


Red, 


CP 


RedCP  +  BlueCP 


Red,  otherwise 
Where  X  ~t/[0,l] 


(C-6) 


Post-Attack  Actions 

The  last  step  in  our  attrition  adjudication  methodology  is  to  determine  the  post  attack  actions  for 
the  convoy.  We  use  a  simple  logic  flow  based  on  the  collective  combat  experience  of  the 
TRAC-MTRY  analysts.  If  the  attack  occurs  in  the  last  35%  of  the  route  then  the  convoy  with 
continue  mission  not  matter  the  outcome  of  the  attack.  If  the  attack  occurs  in  the  first  65%  of  the 
route,  then  the  convoy  must  have  at  least  two  escort  vehicles  and  greater  than  50%  of  its  original 
logistic  vehicle  to  continue  mission,  otherwise  the  convoy  will  return  to  base. 

Iterative  Engagement  Sequence 

We  treat  each  step  of  the  engagement  sequence  as  an  independent  event  so  that  the  probability 
that  the  next  loss  is  red  or  blue  depends  only  on  the  current  force  structure  and  the  parameters 
that  remain  constant  for  the  engagement  sequence.  Figure  C-6  shows  all  possible  iterative  steps 
and  outcomes  for  both  the  annihilation  and  harassment  attack  examples.  The  asterisk  on  the 
right  branches  of  the  harassment  attack  example  indicates  that  the  loss  of  the  Red  CSW  is 
notational  and  serves  only  as  a  stopping  condition. 
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Annihilation  Attack 


Harassing  Attack 


(6,2,2) 


(6,2,2) 


(6,0,2) 


P3=1| 


(2,0,2) 


RTB 


RTB 


(6,1,2) 

(6,2,1) 

\l-P! 

CM 

(6,1,1) 


(4,2,2) 


P3. 


(3,2,2) 

(4,2,1*) 

CM 

CM 

Assumes  Attack  occurs  in 
first  65%  of  route. 

(Blueveh,  BlueEscortl  Redcsw) 

Post-Attack  Action 

Legend 


(5,2,2) 

(6,2,1*) 

Pj/  \>P! 

CM 

) 

(5,2,1*) 

CM 

Figure  C-6.  Two  examples  of  the  attack  adjudication  sequence. 
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Appendix  C  -  An  Example  Implementation  of  the 
Engagement  Adjudication  Methodology  in  Python 


Overview 

This  appendix  contains  commented  Python  code  for  an  example  implementation  of  the 
engagement  adjudication  methodology  discussed  in  Appendix  C.  This  adjudication 
implementation  requires  the  following  six  inputs:  number  of  Blue  logistics  vehicles,  number  of 
Blue  escort  vehicles,  number  for  Red  crew  served  weapons,  Red’s  aggression  level,  Blue’s 
effectiveness  level,  and  the  mode  of  Red’s  effectiveness  level.  From  these  inputs  the 
methodology  produces  the  following  outputs:  remaining  Blue  logistic  vehicles,  remaining  Blue 
escort  vehicles,  remaining  Red  crew  served  weapons  and  Blue’s  post  attack  actions. 

The  first  section  below  documents  the  various  functions  that  serve  as  the  base  for  the 
adjudication  implementation.  The  second  section  includes  the  code  necessary  to  run  the 
implementation  from  command  lining  using  a  comma  separated  value  file  to  provide  the  inputs. 

Attrition  Functions 

The  Python  code  we  include  below  contains  the  various  functions  that  form  the  foundation  of 
this  implementation  of  the  adjudication  methodology.  Where  appropriate,  the  code  references 
the  associated  equitation  or  figures  from  Appendix  C. 

1.  #Import  the  math  and  random  libraries. 

2. 

3.  import  random 

4.  import  math 

5. 

6. 

7.  def  getBlueCombatPower(blue_veh,  blue_escortj  blue_eff ) : 

8.  """Calculate  the  Blue  Combat  Power  at  each  state.""" 

9.  #Calculate  escort  to  log  veh  ratio  (Equation  C-2). 


10. 

11. 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 
21. 
22. 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 


def  getRedCombatPower( red_csw,  red_eff ) : 

"""Calculate  the  Red  Combat  Power  at  each  state. 
#Calculate  Red  Combat  Power  (Equation  C-4). 


def  getRedEff_2(red_eff ) : 

"""Simplified  version  using  only  the  mode  as  input. 
Still  use  tri  dist  with  low,  high  calc'd  off  the  mode. 


#Calculate  Blue  Combat  Power  (Equation  C-3). 


veh_ratio  =  blue_escort/float(blue_veh  +  blue_escort) 


return  RedCP 


return  BlueCP 


RedCP  =  red  csw  *  red  eff 


BlueCP  =  blue  escort  *  blue  eff  *  veh  ratio 
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31.  #Calculate  Red  Effectiveness  (Equation  C-5). 

32.  low  =  red_eff  -  .2 

33.  high  =  red_eff  +  .2 

34. 

35.  redEffOut  =  random. triangular(loWj  highj  red_eff) 

36. 

37.  if  redEffOut  >  1: 

38.  redEffOut  =  1 

39.  else: 

40.  pass 

41. 

42.  return  redEffOut 

43. 

44. 

45.  def  whoLost(BlueCPj  RedCP) : 

46.  . Determine  if  loss  for  a  given  state  change  is  Red  or  Blue 

47.  based  on  the  relative  combat  powers. . 

48.  #Calc  probability  that  loss  is  blue  (Equation  C-6). 

49. 

50.  pBlueLoss  =  RedCP/float(RedCP+BlueCP) 

51. 

52.  #Pull  random  ~U(0jl) 

53. 

54.  roll  =  random. random() 

55. 

56.  if  roll  <=  pBlueLoss: 

57.  loss  =  "Blue" 

58.  else: 

59.  loss  =  "Red" 

60.  return  loss 

61. 

62. 

63. 

64. 

65.  def  getAttackType(aggression) : 

66.  """Determine  whether  attack  is  harrass  or  annihiliation  based  on  aggression  coeff. 

67.  #Equation  C-l 

68. 

69.  roll  =  random. random() 

70. 

71.  if  roll  <=  aggression: 

72.  attack  =  "Annihilation" 

73.  else: 

74.  attack  =  "Harrass" 

75. 

76.  return  attack 

77. 

78. 

79.  def  harassAttack(blue_vehj  blue_escortj  red_cswj  blue_effj  red_eff): 

80.  """Assumptions: 

81.  -  Red  is  targets  Log  Vehicles  first. 

82.  -  Loss  of  Blue  Log  Vehicles  limited  to  ceiling(1.5  x  red_csw). 

83.  -  Red  not  susceptible  to  attrition. 

84.  -  Stopping  conditions: 

85.  -  Red  "Loss". 

86.  -  Max  attrition  reached. 

87. 

88.  #Figure  C-5. 

89. 

90.  i  blue  veh  =  blue  veh 
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91. 

92. 

93. 

94. 

95. 

96. 

97. 

98. 

99. 

100. 
101. 
102. 

103. 

104. 

105. 

106. 

107. 

108. 

109. 

110. 
111. 
112. 

113. 

114. 

115. 

116. 

117. 

118. 

119. 

120. 
121. 
122. 

123. 

124. 

125. 

126. 

127. 

128. 

129. 

130. 

131. 

132. 

133. 

134. 

135. 

136. 

137. 

138. 

139. 

140. 

141. 

142. 

143. 

144. 

145. 

146. 

147. 

148. 

149. 

150. 

151. 


i_blue_escont  =  blue_escont 

blue_veh_lost  =  0 
blue_escort_lost  =  0 

max_blue_loss  =  math.ceil(1.5  *  ned_csw) 

while  (blue_veh_lost  +  blue_escort_lost)  <  max_blue_loss : 

n_blue_veh  =  i_blue_veh  -  blue_veh_lost 
n_blue_escont  =  i_blue_escont  -  blue_escont_lost 

BlueCP  =  getBlueCombatPower(r_blue_vehj  n_blue_escontj  blue_eff) 

RedCP  =  getRedCombatPowen( ned_cswj  red_eff) 

loss  =  whoLost(BlueCPj  RedCP) 

if  loss  ==  "Blue": 

if  n_blue_veh  >  0: 

blue_veh_lost  +=  1 
elif  r_blue_escort  >  0: 

blue_escont_lost  +=  1 
else: 

break 

else : 

break 

f_blue_veh  =  i_blue_veh  -  blue_veh_lost 
f_blue_escort  =  i_blue_escort  -  blue_escort_lost 

outcome  =  (f_blue_vehj  f_blue_escortj  red_csw) 

return  outcome 

def  annihilationAttack(blue_vehj  blue_escortj  red_cswj  blue_effj  red_eff ) : 

" " "Assumptions: 

-  Red  targets  Escorts  first. 

-  Red  is  susceptible  to  attrition. 

-  Stopping  conditions: 

-  Red  loss  =  floor (.5  *  red_csw) 

-  Max  attrition  reached  -  attrition  limited  to  3  x  red  CSW 

^Captures  ability  of  blue  veh  outside  kill  zone  to  avoid  attack 

-  Blue  wiped  out. 

#Figure  C-5. 

i_blue_veh  =  blue_veh 
i_blue_escort  =  blue_escort 
i_red_csw  =  red_csw 

blue_veh_lost  =  0 
blue_escort_lost  =  0 
red_csw_lost  =  0 

##Ifj  then  acception  for  when  initial  CSW  =  1 
if  i_red_csw  ==  1: 

max_red_loss  =  1 
else: 

max_red_loss  =  math. floor ( .5  *  red_csw) 
max_blue_loss  =  min (3*  i_red_cswj  i_blue_veh  +  i_blue_escort) 
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152 

153 

154. 

155. 

156. 

157. 

158. 

159. 

160. 
161. 
162. 

163. 

164. 

165. 

166. 

167. 

168. 

169. 

170. 

171. 

172. 

173. 

174. 

175. 

176. 

177. 

178. 

179. 

180. 
181. 
182. 

183. 

184. 

185. 

186. 

187. 

188. 

189. 

190. 

191. 

192. 

193. 

194. 

195. 

196. 

197. 

198. 

199. 

200. 
201. 
202. 

203. 

204. 

205. 

206. 

207. 

208. 

209. 

210. 


while  ( ( (blue_veh_lost  +  blue_escont_lost)  <  max_blue_loss)  and  (ned_csw_los 
t  <  max_red_loss) ) : 

n_blue_veh  =  i_blue_veh  -  blue_veh_lost 
r_blue_escort  =  i_blue_escort  -  blue_escont_lost 
n_ned_csw  =  i_ned_csw  -  ned_csw_lost 

BlueCP  =  getBlueCombatPowen(n_blue_vehj  r_blue_escontj  blue_eff) 

RedCP  =  getRedCombatPowen( n_ned_cswj  red_eff) 

loss  =  whoLost(BlueCPj  RedCP) 

if  loss  ==  "Blue": 

if  n_blue_escont  >  0: 

blue_escont_lost  +=  1 
elif  r_blue_veh  >  0: 

blue_veh_lost  +=  1 
else: 

break 

else : 

red_csw_lost  +=  1 

f_blue_veh  =  i_blue_veh  -  blue_veh_lost 
f_blue_escort  =  i_blue_escort  -  blue_escort_lost 
f_red_csw  =  i_red_csw  -  red_csw_lost 

outcome  =  (f_blue_veh,  f_blue_escortj  f_red_csw) 

return  outcome 

def  getPostAttackAction(i_blue_vehj  r_blue_veh,  r_blue_escort) : 

"""Determine  if  convoy  continues  mission  (CM)  or  returns 
to  base  (RTB).  If  attack  occurs  after  .65  of  route  covered  then 
always  CM.  If  in  the  first  .65  convoy  must  retain  >=.5  of  original 
logistics  vehicles  and  at  least  2  escorts  to  CM.""" 

loc_roll  =  random. random() 

if  loc_roll  >=  .65: 

action  =  "CM" 
elif  r_blue_escort  <  2: 
action  =  "RTB" 

elif  ( r_blue_veh/f loat(i_blue_veh) )  <  .5: 
action  =  "RTB" 

else: 

action  =  "CM" 
return  action 


def  runAttack(blue_vehj  blue_escortj  red_cswj  aggression  blue_eff,  red_mode): 

####Using  simplied  function  for  red_effj  only  requires  red_mode  input. 
red_eff  =  getRedEff_2( red_mode) 

attackType  =  getAttackType(aggression) 

if  attackType  ==  "Annihilation": 

outcome  =  annihilationAttack(blue_vehj  blue_escortj  red_cswj  blue_effj  r 


ed_eff ) 
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211.  else: 

212.  outcome  =  harassAttack(blue_vehj  blue_escortj  ned_cswj  blue_eff,  ned_eff 

) 

213. 

214.  action  =  getPostAttackAction(blue_vehj  outcome[0]j  outcome[l]) 

215. 

216.  output  =  ((blue_vehj  blue_escontj  ned_csw)j  outcome,  action) 

217. 

218.  return  output 


Execution  Code 

This  section  contains  the  Python  code  necessary  to  run  our  implementation  from  the  command 
line.  This  execution  code  expects  to  receive  a  comma  separated  value  (csv)  file  containing  the 
model  inputs.  The  csv  file  should  have  a  header  row  and  have  columns  in  the  following  order: 
Blue  logistic  vehicles,  Blue  escort  vehicles,  Red  crew  served  weapons,  Red’s  aggression  level, 
Blue’s  effectiveness  level,  and  the  mode  of  Red’s  effectiveness  level  triangular  distribution. 
Figure  D-l  shows  an  example  of  an  appropriately  formatted  input  file. 


A 

B 

C 

D 

E 

F 

1 

Blue  Veh 

Blue  Escort 

Red  CSW 

Aggression 

Blue  Eff 

Red  Mode 

2 

4 

2 

1 

0 

0.5 

0.8 

3 

6 

2 

1 

0 

0.5 

0.8 

4 

8 

2 

1 

25 

0.5 

0.8 

5 

4 

4 

1 

25 

0.5 

0.8 

6 

6 

4 

1 

75 

0.5 

0.8 

7 

8 

4 

1 

75 

0.5 

0.8 

8 

4 

2 

2 

100 

0.5 

0.8 

9 

6 

2 

2 

100 

0.5 

0.8 

10 

8 

2 

2 

0 

0.5 

0.8 

11 

4 

4 

2 

0 

0.5 

0.8 

12 

6 

4 

2 

25 

0.5 

0.8 

13 

8 

4 

2 

25 

0.5 

0.8 

14 

4 

2 

4 

75 

0.5 

0.8 

15 

6 

2 

4 

75 

0.5 

0.8 

16 

8 

2 

4 

100 

0.5 

0.8 

17 

4 

4 

4 

100 

0.5 

0.8 

18 

6 

4 

4 

0 

0.5 

0.8 

19 

8 

4 

4 

100 

0.5 

0.8 

Figure  D-l.  Example  format  for  the  input  comma  separated  value  file. 


1.  #Import  the  sys  and  csv  libraries. 

2.  import  sys 

3.  import  csv 

4.  ##  Attrition_Partl_vl  is  the  .py  file  containing  the  functions. 

5.  import  Attrition_Partl_vl  as  AttritionFunctions 

6. 

7.  ##  initial  set  input  parameters  for  cmd  line  running 

8.  #  the  below  if/else  statement  serve  as  a  logic  check 

9.  #  if  the  user  fails  to  enter  the  proper  number  of  arguments  in  the  command  line 

10.  if  len(sys.argv)  !=  4: 

11.  sys. stderr .write( 'expecting  Command  Line  Arguements:  input_filename.,  output_f ilenam 
e,  number  of  iterations') 

12.  sys.exit(l) 

13. 

14.  else: 
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15. 

16.  input_f ilename  =  sys.angv[l] 

17.  output_filename  =  sys.angv[2] 

18.  iterations  =  int(sys. argv[3] ) 

19. 


20.  row_cnt  =  0 

21. 

22.  result_list  =  [] 

23. 

24.  with  open(input_filenamej  ' r ' )  as  f: 

25.  r  =  csv. reader(f ) 

26. 

27.  #skip  header  row 

28.  r.nextQ 

29. 

30.  #read  in  file  line  by  line 

31.  for  row  in  r: 

32. 

33.  row_cnt  +=  1 

34. 

35.  #Assign  values  to  variables 

36.  blue_veh  =  int(row[0]) 

37.  blue_escort  =  int(row[l]) 

38.  red_csw  =  int(row[2]) 

39.  aggression  =  float(row[3] ) 

40.  blue_eff  =  float ( row[4] ) 

41.  red_mode  =  float(row[5] ) 

42.  #red_high  =  float( row[6] ) 

43.  #red_mode  =  float(row[7] ) 

44. 

45.  #Run  the  specified  number  of  iterations 

46.  for  i  in  range(iterations) : 

47. 

48.  result  =  AttritionFunctions . runAttack(blue_vehj  blue_escortj  red_cswj  aggre 
ssionj  blue_effj  red_mode) 

49. 

50.  result_list.append(result) 

51. 

52.  output  =  open(output_f ilename  ,  'wb')  #establish  output. csv  file  with  handle 

53. 

54.  #Write  Header 

55.  output. write (' Indexj Design  Point j  Blue_Vehj Blue_Escort , Red_CSWj r_B_Vj r_B_ej r_R_csWj Post 
_Attack_Action\n ' ) 

56. 


57 

58 

59 

60 


61. 

62. 

63. 

64. 

65. 

66. 

67. 

68. 
69. 


for  i  in  range(len(result_list) ) : 


output. write 
output. write 
+  str(result_list[i] 
scortj  Red_CSW) 

output. write 
output. write 
output. write 
output. write 
output. write 
output. write 
output. write 


(str(i)  +  ', ') 

(str(result_list[i] [0] [0] )  +  +  str(result_list[i] [0] [1] )  + 

[0] 1 2] )  +  ’ j ' )  #Write  string  of  design  point  (Blue  Vehj  Blue_E 


(str(result 

(str(result 

(str(result 

(str(result 

(str(result 

(str(result 

(str(result 


list [i] [0] [0] ) 
list [i] [0] [1] ) 
.list  [ i ]  [0]  [2] ) 
list [i] [1] [0] ) 
list [i] [1] [1] ) 
.list  [ i ]  [1]  [2] ) 
.list [i]  [2] )  +■ 


+ 
+  ' 
+  ' 
+  ' 
+  ' 
+  ' 
\n ' 


#write 

inital 

Blue 

Veh 

#write 

inital 

Blue 

Escort 

#write 

inital 

Red 

CSW 

#write 

final 

Blue 

Veh 

#write 

final 

Blue 

Escort 

#write 

final 

Blue 

CSW 

#write 

Post  Attack 

Action 

output . close( )  #always  close 
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Calling  the  Execution  Code  from  the  Command  Line 

To  call  the  execution  code  from  the  command  line  the  following  structure  is  required: 

python  Attrition _Part2_v2.py  test_design.csv  output. csv  1000 

After  identifying  the  program  used  this  command  line  call  includes  the  python  file  contain  the 
execution  code  as  the  first  argument.  The  second  and  third  arguments  are  the  input  and  output 
csv  files,  respectively.  The  forth  agreement  is  the  number  of  iterations  being  run. 
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Appendix  E  -  Glossary 

ADT 

Attrition  Distribution  Tool 

CSW 

Crew  Served  Weapon 

FLVN 

Fort  Feavenworth 

LBC 

Fogistics  Battle  Command 

MTRY 

Monterey 

TRAC 

TRADOC  Analysis  Center 
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